fix: keep qa report and artifact listings inside the protocol frame - #83

Closes #14.

The bug

A full diagnostic report is 500 events, each holding up to a 4 KiB message and an 8 KiB URL — roughly 2 MB against a 1 MiB frame. encodeLine threw inside handleClient, fell into the generic catch, and the agent received:

INVALID_REQUEST  messageTooLarge

…for a request the host had accepted and executed successfully. There was no escape hatch: no pagination, no way to ask for less. artifacts list had the same unbounded exposure as the store grew over a long session.

The fix

Bounded responses that say what they dropped, matching the pruning contract used everywhere else in the product:

• qa report trims its issues and events arrays to a byte budget, keeping the newest — those are what an agent is diagnosing. Crucially the summary counts still describe every collected event, so the numbers stay honest when the payload is trimmed.
• artifacts list returns the newest 250 with total and omitted.
• Both set truncated.

The transport now separates "this response cannot be framed" from "your request was bad", answering RESPONSE_TOO_LARGE with a suggestion (--limit, or headless qa clear). That path should be unreachable for these two commands now, but it is the honest fallback for any future response that outgrows the frame.

Tests

Two new cases in the protocol suite: a report built from 500 × 4 KiB events, and a store holding 260 artifacts. Both assert the encoded response fits headlessMaximumMessageBytes and that kept + omitted accounts for everything. The first fails on main.

Design note

Per architecture decision §4, response-side bounding was already sanctioned as a compatible addition, so no new decision entry is needed. I chose truncation now over cursor pagination: it is compatible, needs no wire-visible protocol addition, and makes the failure mode honest immediately. Cursor pagination is the richer answer and stays tracked as §G3 — worth doing when console list/network list want the same primitive.